REMARKS 



This amendment is intended to place the subject application in condition for 
allowance. Specifically, independent Claims 1, 27, 28 and 35 were amended. In view 
of the amendment and the following reasoning for allowance, the applicants hereby 
respectfully request further examination and reconsideration of the subject application. 

1. Interview Summary 

A telephonic interview was held on August 7, 2008 between the undersigned and 
Examiner C. H. Nguyen. During this interview, the 35 USC §101 and 35 USC §1 03(a) 
rejections of the above-identified Office Action were discussed. The applicant's 
representative presented arguments for patentability that are now proffered in this 
response. The Examiner stated that these arguments would likely be persuasive in 
regards to the 35 USC §101 rejection. In regard to the 35 USC §103(a)rejection, the 
Examiner did not commit one way or the other as to whether the changes made to the 
independent claims overcame the rejection, but stated dependent Claims 9, 16 and 33 
might be patentable in view of the arguments. 

2. The Section 101 Rejection of Claim 27 

Claim 27 was rejected under 35 USC 101 as being directed toward non-statutory 
subject matter. In essence, the Examiner contends that the claims are directed toward 
what amounts to a computer program perse. The applicant respectfully disagrees. 

The applicant is not claiming a computer program perse as contended in the 
Office Action. Generically, the preamble of independent Claim 27 reads: 

"A computer-implemented process for..., comprising using a computer to 
perform the following process actions:" 
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Thus, the applicant is claiming a process implemented on a computer where the actions 
of the process are performed using the computer. This is statutory subject matter. 

As stated in the MPEP (see Section 2106.01 (1) at Page 2100-18, Rev. 6, September 
2007): 

"Computer programs are often recited as part of a claim. USPTO 
personnel should determine whether the computer program is being 
claimed as part of an otherwise statutory manufacture or machine. In such 
a case, the claim remains statutory irrespective of the fact that a computer 
program is included in the claim. The same result occurs when a 
computer program is used in a computerized process where the 
computer executes the instructions set forth in the computer 
program ." (emphasis added) 

Clearly, in the case of Claim 27, the actions are being claimed as part of a 
statutory process-namely a process with actions that are performed using a computer. 
Accordingly, given that Claim 27 is directed toward statutory subject matter, it is 
respectfully requested that the rejection be reconsidered. 

3. The Section 103(a) Rejection of Claims 1-38 

Claims 1-38 were rejected under 35 (JSC 103(a) as being obvious over Ho et al., 
U.S. Patent Application Publication No. 2005/0066284, in view of Salesky et al., U.S. 
Patent No. 6,343,313. It was contended in the Office Action that Ho teaches all the 
elements of the rejected claim with the exception of a display module which receives layout 
instructions and data from the layout module and employs the same to display content on 
the shared display device. However, it is further contended that this feature is taught in 
Salesky. Thus, it was concluded that it would have been obvious to incorporate the 
teachings of Salesky into Ho to produce the applicants' claimed invention. In response, the 
applicants have amended these claims to make them patentable over the cited 
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combination. More particularly, independent Claims 1, 27, 28 and 35 have been amended 
to include a recitation of what kind of user-inputted information is input and used to display 
content on a shared display. 

The applicants now claim: 

"a logic module comprising an application which based on the user- 
inputted information generates display instructions and data, 
wherein said user-inputted information comprises at least one of 
video data or audio data or document data, a layout module which 
based on the display instructions and data from the logic module 
generates layout instructions and packages data for display, and a display 
module which receives the layout instructions and data from the 
layout module and employs the same to display content in the 
shared display on the display device" (see Claims 1-26); 

"establishing multiple input modalities to input information from multiple 
users, wherein at least one of the input modalities is characterized by a 
latency greater than about 1.0 second, and wherein said user-inputted 
information comprises at least one of video data or audio data or 
document data; and inputting the user information from the multiple input 
modalities to a single computer program which employs the user 
information to control the content displayed in the shared display on 
the display device" (see Claim 27) 

"a plurality of input modules each providing a different input modality at 
least one of which is characterized by a latency exceeding about 1 
second, and which collectively input information from multiple users, 
wherein said user-inputted information comprises at least one of 
video data or audio data or document data, an application module 
which receives the user information from the input modules and 
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which based on the information generates display layout 
instructions and packages data for display, and a display module 
which receives the layout instructions and data from the application 
module and employs the information and data to display content in 
the shared display on the display device" (See Claims 28-34) 

"establishing multiple input modalities to input information from multiple 
users, wherein at least one of the input modalities is characterized by a 
latency greater than about 1.0 second, and wherein said user-inputted 
information comprises at least one of video data or audio data or 
document data; and inputting the user information from the multiple input 
modalities to a single computer program which employs the user 
information to control the content displayed in the shared display on 
the display device" (See Claims 35-38). 

The feature in the foregoing claims "wherein said user-inputted information comprises at 
least one of video data or audio data or document data" will be referred to in the following 
argument as the input data feature. The feature in the foregoing claims where the inputted 
user information is used to control or display the content in the shared display on the 
display device will be referred to in the following argument as the shared display feature. 

The Ho-Salesky combination does not teach either the claimed input data or the 
shared display features. The Examiner has already stated in the Office Action that Ho 
does not teach a display module which receives layout instructions and data, and employs 
the same to display content in the shared display. Thus, Ho does not teach the claimed 
shared display feature. Ho also lacks a teaching of the claimed input data feature as there 
is no mention of user-inputted information being used to generate layout instructions and 
data for a shared display that include at least one of video data or audio data or document 
data. Salesky also lacks these teachings. 

More particularly, Salesky describes a shared display that is shown on a display 
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device and whose content comes almost exclusively from prescribed sections of the 
display screens associated with one or more presenters. Thus, Salesky's shared display is 
generated from inputted images. The only exceptions involve coordinates for generating 
and locating pointers associated with certain participants, and certain commands (such as 
one to change the color map). None of these inputs involves video data or audio data or 
document data. 

Granted, the Examiner contended in the Office Action that Salesky did teach a user 
inputting video data, audio data and document data, which would then presumably used in 
generating the shared display. The applicants respectfully disagree. As to video and audio 
data, the Examiner in rejecting Claims 24 and 25, indicated Salesky teaches their input via 
Fig. 8B and it description at Col. 23, lines 1-44. However, the only inputs shown in that 
figure and description that might be construed as video or audio are the replay inputs. 
More particularly, the cited section of Salesky reads: 

"FIG. 8B illustrates a more complex conference server which handles the 
more general case. The server in the general case might maintain additional 
output and additional input queue components for transmitting information to 
other servers and for storage services, including caching, short-term storing, 
recording, and archiving, and for later playback. These purposes are 
distinguished as follows: caching provides fast memory hardware support in 
improving the performance of the server; short-term storage provides backup 
and refresh capability for extremely slow or temporarily disconnected clients, 
for newly connected servers that may need information older than that 
normally held in the output queue, for quick-turnaround failure recovery, and 
for other short-term needs; conference sessions are recorded when they 
are primarily intended for later viewing by users of the system who may 
or may not be participating in the session; an archival session captures 
all or part of a meeting as it occurs and is intended for users who 
typically were conferees in that session and have a reason to review the 
session later. Uses of recorded sessions, especially when they incorporate 
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synchronized voice, include live online training sessions that also serve for 
future offline training, technical and marketing demonstrations, and formal 
presentations that can be broadcast or accessed remotely at will. Archived 
sessions have uses other than review, including briefing absentees, capturing 
interactions involving or aiding technical support, evaluating sales personnel, 
and the like. Of course, these needs and characterizations are not exclusive 
or exhaustive. 

Possible features and methods for storage handling will now be listed. The 
emphasis will be on recording and archiving, but shorter term storage modes 
will share many of these characteristics. 

During any session, there can be multiple "storage server" queues, or 
"storage streams," saving output to one or more media. These can be 
controlled by the server itself, by recorder-like interfaces (similar to a video 
cassette recorder, or "VCR") at the clients, or by other interfaces operated by 
conferees. Each stream can be independently controlled, or one controller 
can control multiple storage streams. The storage facility can operate 
concurrently in an ongoing meeting to record a live conference, or it can be 
used by itself to capture a recording for later replay", (emphasis added) 

As can be seen from the foregoing excerpt, the replay inputs are used in non-conference 
situation to review a previously held conference. The replay data is not used to generate a 
shared display, only to show a previously created one. A person viewing a replayed 
conference cannot change the shared display by entering video or audio data. 

In regard to document data, the Examiner in rejecting Claim 26, indicated Salesky 
teaches its input at Col. 30, lines 15-62. This section of Salesky reads: 

"A potential conferee 17(a) has navigated his or her WWW browser to Web 
server 30(a), and has asked through the Web page presented to connect to 
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the meeting (as described above in the discussion of FIG. 2). There may be 
alternative ways, indicated here as 30(b),(c), to connect to the meeting, 
including direct access to the meeting manager or its database 34 (called 
here "Meeting DB"). The meeting manager uses this database to hold 
information concerning the meeting (the database need not be on the same 
computer as the meeting manager). This information was created when the 
person who set up the meeting requested that the meeting be scheduled, 
gave descriptive information for the meeting, specified the keys and 
privileges, and provided other administrative information. The database is 
reconfigurable and easily extensible to include many and varied meeting 
attributes. It may be accessed by a programming interface. Potential new 
conferee client 17(a) sends a request to join the meeting, and then 
supplies the key for the meeting that the potential conferee has 
obtained previously. Potential client 17(a) may also send previously 
selected identification information such as icon, gong, etc., and this may 
be stored in Meeting DB or in some other sort of directory service. After the 
meeting manager has validated potential client 17(a), it sends a message that 
causes the client software to run on the potential client and then sends that 
client software the address information for the CSS, such as a URL and port 
number. At that time, the client software may also receive address 
information for backup CSSs in case the connection to the meeting fails and 
automatic or manual attempts to reconnect to the initial CSS fail as well. The 
client then connects to the meeting, and may pass to the CSS its 
identification information. 

A CSS is created to supervise a single meeting. The monitoring-filtering- 
queueing structures and procedures of FIGS. 8A,B are performed by the 
CSS, so FIGS. 8A,B could be viewed as part of the internal working of each 
CSS in FIGS. 1 1-22 (in the case of distributed server functions described in 
FIGS. 9D-F, only part of FIGS. 8A,B might be descriptive of a particular 
CSS). Indeed, there will be a version of FIG. 8A applying to each data stream 
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the CSS handles as multipoint real-time traffic from a presenter client. The 
structure of FIG. 8B shows schematically how these and other multiple input 
and output data streams are processed. The CSS also handles other input 
from and output to clients, such as information about attendee and presenter 
clients that helps with flow control, commands or requests from clients, 
labeled pointer icon positions, and other stream data and control traffic". 

As can be seen in the foregoing excerpt, the only discussion of user inputs involves a 
request to join, keys, potentially identification information, request for attendee/presenter 
information, and so on. None of this is document data that is input to control or display 
content in the shared display. 

In order to deem the applicant's claimed invention unpatentable under 35 USC 103, 
a prima facie showing of obviousness must be made. To make a prima facie showing of 
obviousness, all of the claimed elements of an applicant's invention must be considered, 
especially when they are missing from the prior art. If a claimed element is not taught in 
the prior art and has advantages not appreciated by the prior art, then no prima facie case 
of obviousness exists. The Federal Circuit court has stated that it was error not to 
distinguish claims over a combination of prior art references where a material limitation in 
the claimed system and its purpose was not taught therein (In Re Fine, 837 F.2d 107, 5 
USPQ2d 1596 (Fed. Cir. 1988)). 

In this case, the cited combination does not teach the claimed input data or the 
shared display features. The cited combination also fails to recognize advantages of 
these features such as allowing a shared display to be controlled with modalities other 
than shared image data. Thus, the applicants have claimed a feature not taught in the 
cited combination, and which has advantages not recognized therein. Accordingly, no 
prima facie case of obviousness can be established in accordance with the holding of In 
Re Fine. This lack of prima facie showing of obviousness means that the rejected 
claims are patentable under 35 USC 103 over Ho in view of Salesky. It is, therefore, 
respectfully requested that Claims 1-38 be allowed based on the previously-quoted 
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claim language. 



In further regard to Claim 9, the applicants claim, "each input module is in 
communication with each of the other input modules, and wherein each input module 
comprises a timestamp sub-module which appends onto each message or a part 
thereof received from a user that is provided to the logic module, an indicator identifying 
the time the message was received, and wherein each input module comprises a sub- 
module for coordinating with the other input modules to provide each message or 
portion thereof to the logic module only after any message or part thereof received by 
another input module with an earlier timestamp has been provided to the logic module". 
The Examiner contends in the Office Action that this is taught in Salesky at Col 1 5, lines 
1-35. The section of Salesky reads: 

"When a new conferee joins a meeting or before, the conferee selects a 
personal icon and a characterizing sound (a "gong") which will be the icon 
and gong that other conferees will associate with the joining conferee. 
Icons and gongs can be created using well-known techniques for creating 
icons and audio data. When a new conferee joins a meeting, the conferee 
client sends his or her personal icon and gong to each other client, via the 
conference server. The new conferee is then "announced" by the gong. 
The personal icon of the joining conferee is also added to a conferee icon 
list maintained on the server or at each client. If another conferee chooses 
to have the icon list displayed at his or her client, the entrance of the 
joining conferee can be noted when the new icon appears on the icon list. 
Other personal information about the conferee, such as name and 
electronic mail ("email") address may be provided by the conferee and 
made available to other conferees via the server. As described earlier, the 
visibility of icons, audibility of gongs, access to personal information, and 
so on, may be based on the key the conferee used to enter the meeting, 
on the identity of the conferee (by network address or otherwise), or on a 
combination of these and other validators. 
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The presenter can "go off-air," i.e., suspend or pause the image capturing 
process and can "go on-air," i.e., resume the presentation at will. The 
network connections can be maintained during the off-air period, but no 
changes will be sent to the server. Similarly, an attendee can request to 
be off-air, and no changes will be sent or scheduled by the server during 
the off-air time. 

If clients are so configured, conferees can be given lists or iconic 
representations of the participants in the conference, as mentioned above. 
Those conferees that are presenting, those who are off-air, and those who 
are requesting to present can be marked. Various subsets of conferees, 
for example those in side-conversations, those in other meetings, those 
connected to a particular server, and in general those selected by some 
property of the system's current configuration, can also be marked. The 
visibility of the lists and the presence of any markings may be controlled 
by users, administrators, or others, based on privileges or other criteria. In 
addition, graphical representations of a meeting or part of a meeting, or of 
several meetings, may be available for display, depending on privileges". 

There is absolutely nothing in the foregoing excerpt to suggest that the input modules are 
in communication with each other, or that they include timestamp sub-modules, or that they 
include sub-modules for coordinating timestamps with each other. 

As such, the cited combination does not teach the above-quoted features, and 
fails to recognize advantages of this feature such as coordinating timestamps between 
different input modules. Thus, the applicants have claimed another feature not taught in 
the cited combination, and which has advantages not recognized therein. Accordingly, 
no prima facie case of obviousness can be established in accordance with the holding 
of In Re Fine. This lack of prima facie showing of obviousness means that rejected 
Claim 9 is also patentable under 35 USC 103 over Ho in view of Salesky for the 
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foregoing reason as well. 



In further regard to Claim 16, the applicants claim, "the application associated 
with the logic module comprising one of (i) a computer game, (ii) an electronic bulletin 
board, (iii) a voting/polling tool, (iv) a web browsing tool, (v) a computer graphics 
program or (vi) a lottery tool". The Examiner contends in the Office Action that this is 
taught in Salesky at Col 23, lines 1-33. The section of Salesky reads: 

"FIG. 8B illustrates a more complex conference server which handles the 
more general case. The server in the general case might maintain 
additional output and additional input queue components for transmitting 
information to other servers and for storage services, including caching, 
short-term storing, recording, and archiving, and for later playback. These 
purposes are distinguished as follows: caching provides fast memory 
hardware support in improving the performance of the server; short-term 
storage provides backup and refresh capability for extremely slow or 
temporarily disconnected clients, for newly connected servers that may 
need information older than that normally held in the output queue, for 
quick-turnaround failure recovery, and for other short-term needs; 
conference sessions are recorded when they are primarily intended for 
later viewing by users of the system who may or may not be participating 
in the session; an archival session captures all or part of a meeting as it 
occurs and is intended for users who typically were conferees in that 
session and have a reason to review the session later. Uses of recorded 
sessions, especially when they incorporate synchronized voice, include 
live online training sessions that also serve for future offline training, 
technical and marketing demonstrations, and formal presentations that 
can be broadcast or accessed remotely at will. Archived sessions have 
uses other than review, including briefing absentees, capturing 
interactions involving or aiding technical support, evaluating sales 
personnel, and the like. Of course, these needs and characterizations are 
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not exclusive or exhaustive. 



Possible features and methods for storage handling will now be listed. The 
emphasis will be on recording and archiving, but shorter term storage 
modes will share many of these characteristics". 

There is absolutely nothing in the foregoing excerpt to suggest that the claimed logic 
module includes a computer game, or an electronic bulletin board, or a voting/polling tool, 
or a web browsing tool, or a computer graphics program, or a lottery tool. 

As such, the cited combination does not teach the above-quoted logic module 
feature, and fails to recognize advantages of this feature such as providing the 
participants with something other than screen shots in the shared display. Thus, the 
applicants have claimed another feature not taught in the cited combination, and which 
has advantages not recognized therein. Accordingly, no prima facie case of 
obviousness can be established in accordance with the holding of In Re Fine. This lack 
of prima facie showing of obviousness means that rejected Claim 16 is also patentable 
under 35 USC 103 over Ho in view of Salesky for the foregoing reason as well. 

In further regard to Claim 33, the applicants claim, "the application module 
comprises a sub-module for archiving the identity of each user requesting data, as well 
as when the information was requested and what data was provided to the user". The 
Examiner contends in the Office Action that the reasons for rejection this claim were 
discussed with respect to the rejection of Claims 1-9. However, while Claims 5-9 do 
involved data output to a user, these claims do not address the archiving of "the identity 
of each user requesting data, as well as when the information was requested and what 
data was provided to the user". The cited Ho-Salesky combination also lacks any 
mention of this type of archiving. 

As the cited combination does not teach the above-quoted archiving feature, and 
fails to recognize advantages of this feature such as tracking user requests and the 
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responses thereto, the applicants have claimed another feature not taught in the cited 
combination, and which has advantages not recognized therein. Accordingly, no prima 
facie case of obviousness can be established in accordance with the holding of In Re 
Fine. This lack of prima facie showing of obviousness means that rejected Claim 33 is 
also patentable under 35 USC 103 over Ho in view of Salesky for the foregoing reason 
as well. 

Finally, it is noted that while the applicants have provided arguments to show that 
Ho does not teach certain elements of the rejected claims, no admission is made that 
Ho is a proper reference for the subject 35 USC 1 03 rejection. Ho was filed less than 4 
months prior to the subject application. As such the applicants reserve the right to 
swear behind Ho to eliminate it as a reference should the rejection be sustained. 

4. Summary 

In summary, it is believed the claims are in condition for allowance. As such, 
reconsideration of the rejection of Claims 1-38 is respectfully requested. In addition, 
allowance of these claims at an early date is courteously solicited. 
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